Supporting Synchronous Groupware with Peer Object-Groups

We propose the peer object-group design pattern as a suitable architectural solution to structure and implement synchronous groupware applications. We discuss a reliable group-communication subsystem and a distributed objects model, implemented in Java, used to realize the approach. 1. Characterizing Groupware "Computer Supported Cooperative Work" CSCW, deals with the use of computer systems by people to cooperatively work on common tasks. Groupware is software specially built to allow people to work cooperatively. Groupware and user interaction can be roughly classified in two broad classes asynchronous or different-time, and synchronous or same-time. When using asynchronous groupware, users work not necessarily in the same time-frame and interact for long periods of time (e.g. in the joint development of a software project). When using synchronous groupware users work in a tightly-coupled manner during relatively short common time-frames (e.g. during a distributed meeting). The synchronous and asynchronous cooperation paradigms are not alternatives, but rather complementary; real work is most often performed alternating asynchronous work with synchronized periods. We are in the process of investigating generic system-level services to support and allow simple development of robust groupware applications. In this text we will focus on system support for synchronous groupware. In particular, we will discuss structuring and programming abstractions based on groupcommunication and object-groups specially devised to help in the development of synchronous groupware applications (SGA). A virtually common feature to all SGA is the provision of a shared workspace which users use to communicate and cooperate during a synchronous session. For acceptable productivity, users need to have an accurate notion of what the state of the shared workspace is. In particular, users should have mutually consistent views of the state of the workspace and should see each others actions as soon as possible. SGA are also interactive applications by nature, so it is required that the system responds and evolves accordingly to users expectations [1]. Users desire short or immediate response times; preferably, similar to that found in single user applications. Users do not find acceptable to wait a considerable amount of time to perform some operation (e.g. to update a shared object). Because users tend to divide/phase tasks into smaller sub-tasks and user communication and cooperation has multiple facets, SGA should be seen not as monolithic applications but rather as a collection of tools aggregated in the context of a single session (e.g. including a tool for shared drawing, a tool for message exchanging, a tool for text or document editing, tools providing audio and video channels, user activity awareness, coordination, etc.). From a software-engineering perspective, it is also preferable to use a generic multi-tool approach than to provide all the functionality from scratch in every application. 2. Design Alternatives to Support Distributed Synchronous Groupware A commonly used architectural approach to support distributed SGA is the client-server paradigm. A central server is used to manage the shared workspace, to perform concurrency control on user accesses, and to provide other session related services (e.g. user activity awareness). User processes use the server to operate on shared resources and to disseminate information to other users. While this is a very well understood paradigm, and it is simple to realize, it presents major drawbacks: fault-tolerance and scalability, since it is based on a central server. Moreover, performance can be somewhat injured by this architectural approach, although clients may replicate/cache parts of shared workspace in order to mitigate the problem. A variation is the centralized application-distributed interface approach, where a single application multiplexes user interaction and disseminates output across several user interfaces. It presents the same problems as the client-server approach, and is in general less flexible. An alternative is the replicated-server, or objectgroup, approach. A group of servers actively replicates objects and/or service state. Even if a subset of servers crashes or becomes unreachable, the service will be available as long as some of them remain reachable (one or the majority depending on consistency criteria). This approach is very suitable for many distributed fault-tolerant services, but still presents some drawbacks in the context of SGA. Because users want to have accurate views of the shared workspace, and because users actions are largely driven by other users actions, extra mechanisms for event notifications are required. Preliminary experience on scalable, fault-tolerance, distributed systems has suggested that migrating complex system functionality from servers to clients may be a suitable design option. This argument, the need for flexibility in tool building, and the lowlatency requirements of SGA, suggests, in our view, a much more natural approach the peer objectgroup approach. 3. The Peer Object-Group Design Pattern In the peer object-group approach the shared workspace managed by SGA is materialized as a collection of objects replicated amongst users local environments. Each local environment holds a replica for every object the associated user is currently working on or accessing with. The set of replicas for a given object constitutes a (peer) object-group. Consistency amongst the replicas is kept by a groupcommunication subsystem implementing appropriate consistency criteria. Shared objects are mapped to object-groups and operations on the objects are mapped to (reliable) multicast operations. Figure 1 schematically illustrates the model. Users gain access to objects by dynamically joining the corresponding object-groups which may involve the transparent transfer of the object's current state to the local replica. When no longer interested in the objects, users leave the object-groups. Users keep accurate views of the shared state since updates are received by all object-group members; no provisions for additional notification mechanisms is required. Latency in object manipulation is improved because no intermediate entities are present. Fault-tolerance and availability is also improved; a K-degree of fault-tolerance is achieved as long as K+1 members keep copies of shared objects.